COMMENTS 

The enclosed is responsive to the Examiner's Final Office Action mailed 
on April 8, 2002; and, is included with a Continued Prosecution Application 
(CPA) as provided under CFR 1 .53d that is being filed herewith. At the time the 
Examiner mailed the Office Action, claims 1-27 were pending. In the present 
response, the Applicant has: 1) amended claims 1-6; 2) canceled claims 8-27; 
and 3) added new claims 28-48. As such, claims 1-6 and 28-48 are currently 
pending. The Applicant respectfully requests reconsideration of the present 
application and the allowance of each of claims 1-6 and 28-48. 

Various comments regarding the present application are provided below. 
These comments are broken down into three sections: 1) Basic Concepts; 2) 
The Applicant's Disclosure; and, 3) The Applicant's Claims. The Basic Concepts 
section discusses some very basic concepts that are well known to those of 
ordinary skill. Although the Examiner is already well versed with respect to this 
material, its serves as a useful backdrop of information against which further 
prosecution of the present application may be applied. The Applicant's 
Disclosure section summarizes relevant portions of the Applicant's specification 
so that the subject matter that supports the Applicant's claims can be efficiently 
conceptualized. The Applicant's Claims section provides an analysis of the 
Applicant's claims against the prior art cited by the Examiner in the Office Action 
mailed on April 4, 2002. 
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Basic Concepts 

The present application concerns a "cost-effective" hardware platform that 
can be used, for example, to provide different types of networking service (e.g., 
Voice, ATM, Frame Relay) over a particular physical link (e.g., a T1 line). As 
such, it is prudent to reveal some underlying concepts regarding networking 
technology that are well known and understood by those of ordinary skill. In 
particular, note that a single physical link can be viewed as a mere physical 
means for transporting information from one geographic region to another 
geographic region. For example, a copper wire that runs from one building to 
another building can be used to transport information from the first building to the 
second building. 

A physical link typically formats the information according to a particular 
scheme so that the information can be reliably transported from its source to its 
destination. In the case of the particular embodiment revealed in Figure 3 of the 
Applicant's application, the type of formatting used for the physical transportation 
of information from one geographic region to another geographic region is 
referred to as "T1/E1". Hence, the physical links being employed in the 
embodiment observed in Figure 3 are often referred to by those of ordinary skill 
as"T1/E1 networking lines", "T1/E1 links", "T1/E1 lines", "T1/E1 physical lines", 
and the like. Note page 10, lines 15 -17 of the applicant's application: "[i]n the 
egress direction, the . . . bit stream from the TDM switch 322 is processed by the 
T1/E1 framer and sent out over the T1/E1 physical line" [emphasis added]. 
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The term "T1/E1" refers to a particular type of data formatting, known as 
"framing" that is implemented upon the physical line. The history of "framing" is 
derived from challenges faced by traditional telephone networks. In particular, 
framing allowes multiple, simultaneous telephone calls/conversations to be 
carried over a single wire. Here, through a technique known as "time division 
multiplexing" (TDM) different channels (each of which may be used to carry to a 
different call or connection) are "stuffed" onto the same physical line by 
organizing specific moments in time that each channel "gets to use the line". 

That is, each different channel is given a particular slot of time (or "time 
slot" ) within an overall frame; and, consecutive frames are sent "one after the 
other" on the line so that, over time, the traffic for any particular call is suitably 
transported. T1 refers to a framing technique (used largely in the United States) 
that includes 24 channels per frame. E1 refers to a framing technique (used 
largely in Europe) that includes 32 channels per frame. A T1/E1 framer, as is 
known the art, is a framing device capable of sending/receiving T1 or E1 frames 
on a physical line to which it is coupled. Although framing's roots are directed to 
simultaneous transportation of multiple voice conversations over a single wire, 
other uses have emerged. 

In particular, T1/E1 lines have also been used for the transportation of 
data (e.g., data files, electronic messages, etc.). Some typical networking 
service types that are capable of transporting data, to name just a few, include 
ATM, Frame Relay and HDLC. Data transportation often involves the formation, 
sending and reception of discrete encapsulations of data (e.g., packets, cells, 
etc.). A notable exception involves traditional facsimile transmissions where data 
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is transported via specific tone(s) and thus is more akin to a standard voice 
conversation. Nevertheless, for those situations where data is transported with 
packets or cells, note that these packets or cells are usually "kept track of" (or 
are otherwise managed) at higher architectural levels of the network than the 
physical lines themselves. 

This, in turn, involves the "re-organization" of data as between its 
particular type of data transportation technique and the particular framing 
technique that is employed on a physical line. For example, a typical process 
flow for using a T1 line to transport ATM cells would include: 1) in the egress 
direction, the breaking down of an ATM cell into smaller pieces that each 
consume one time slot in a T1 frame; and, 2) in the ingress direction, the 
collection and recombination of data that was carried by multiple T1 time slots 
into an ATM cell. In this case where, for example, data is being transported by a 
pair networking machines that communicate to one another over a T1 line - note 
that the data can be managed mostly in the form of an ATM cell by the 
networking machines - except for those moments in time when the data is being 
transported over the T1 line (or is being prepared for transportation over the T1 
line or is being received after transportation upon the T1 line). 

With the understanding that traditional framing techniques can be used to 
transport not only voice traffic but also data traffic (wherein, in the case of data 
traffic some form of processing is used "above" the framing level to re-organize 
the data into its appropriate discrete unit or grouping of data such as an ATM 
cell, a Frame Relay data unit, etc.), note that various mixtures and combinations 
of different transportation services are possible. For example, one T1 line could 
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be used to handle voice transportation while another T1 line could be used to 
handle data transportation. Further still, a single T1 line could be used to handle 
some voice transportation (e.g., within a first group of channels) and some data 
transportation (e.g., by transporting ATM cells with a second group of channels). 



Applicant's Disclosure 

With underlying, basic and well known concepts being re-viewed just 
above, it is to be understood that the teaching s of the present application can be 
directed to the implementation of various flavors of service combinations (e.g., as 
described just above) in a "cost-effective" manner. Notably, whereas prior art 
solutions used different hardware designs in order to implement different 
services (e.g., an "ATM over T1/E1" card, a "Frame Relay over T1/E1" card, 
etc.), the present application is directed to a single hardware design that is able 
to support different types of networking services. Figures 2 and 3, when viewed 
together, disclose a complete software and hardware solution for providing 
different types of service (e.g., voice, Frame Relay, ATM, HDLC, a combination 
thereof, etc.) over one or more T1/E1 lines that emanate from the same feature 
card. Here, some excerpts from the application are particularly noteworthy. 



The disadvantages of the current technology are 
many. For example, because a hardware board . . . 
designed for a given network application is only 
capable of supporting that network application, 
different hardware boards are required to support 
different network applications (e.g., Voice, ATM, 
Frame Relay). This multiplies the efforts in 
development, testing, integration and support of a 
network product. Additionally, current technology 
leads to a greater inventory for a service provider 
because a service provider must keep in stock a 



09/270,297 



12 



081862.P146 





sufficient number of hardware boards of different 
support capabilities. 



See, Page 



2, lines 9 - 17 of the Applicant's application. 



A multi-service architecture that supports "Any Port 
Any Service" (APAS) for use in . . . multi-service 
networking products is described. . . . [S]oftware can 
be invoked to support the desired service type 
(HDLC/FR/ATM, etc.) while using the common 
hardware. The software can configure any port for 
any of the desired service types. In this way, different 
service types can be supported simultaneously on 
different ports. 



See, Page 5, lines 3 - 10 of the Applicant's application. 

The ability to provide any type of service (from amongst a collection of 
possible services such as Voice, ATM, Frame Relay and HDLC), at any channel 
and line combination, is made possible through the use of different functional 
components that perform appropriate networking service functions for each 
line/channel combination. For example, if a first channel on a T1/E1 line is to 
support ATM service and a second channel on the same T1/E1 line is to support 
Frame Relay service, a first functional component will perform "ATM" functions 
upon the data that is sent/received on the first channel; and, a second functional 
component executes "Frame Relay" functions upon the data that is sent/received 
on the second channel. 

Here, the different functional components may be viewed, in part, as 
different pieces of "service specific" software (e.g., ATM software, Frame Relay 
software, Voice software, etc.) that are downloaded onto the common hardware 
platform and are executed by an appropriate processor. The execution of the 
"service specific" software allows the hardware platform to perform 
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corresponding "service specific" functions. As such, different types of services 
(e.g., voice, ATM, Frame Relay) and combinations thereof can be easily 
configured and provided as needs arise. The following excerpts from the 
Applicant's application are relevant to this perspective. 



By downloading an appropriate software image, the 
common hardware can be configured to support 
various services including but not limited to T1/E1 
voice application, channelized [Frame Relay] 
application, unchannelized [Frame Relay] application, 
T1/E1 ATM application, serial 
Asynchronous/Bisynchronous mode applications or 
any combination across the ports, depending on the 
application and the corresponding software images. 

Applicant's Application page 5, lines 11-16. 

Figure 2a is block diagram of an APAS configuration . 
. . [t]he system is . . . comprised of various software 
images 200i ... 200 N dependent on a set of network 
service applications 202i ... 202 N . For one 
embodiment, the applications 202^ ... 202 N may be, 
but are not limited to, [a Frame Relay] application, an 
ATM application or a digital voice application. 

Applicant's Application page 6, lines 19-25. 

In order to support different applications 202i ... 202 N 
such as digital voice, ATM, [Frame Relay] or serial 
applications, the same feature card may be used ... 
[T]wo ports may support a different type of application 
202 within the same feature card 20. For this 
scenario, two different types of software images 200i 
and 200 2 may be run on a processor that supports 
two different applications. 

Applicant's Application page 7, lines 8-9 and 16-19. 

The above cited paragraphs in combination with Figure 2a clearly disclose 

that individual pieces of "service specific" software programs (i.e., "software 

images") are downloaded to a card and executed by that card so that the card is 
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able to provide whatever combination of services are desired for that card. For 
example, the dashed lines and arrows of Figure 2a clearly indicate that if feature 
card 20 is to provide Frame Relay service and ATM service, both the Frame 
Relay software image 200i and the ATM software image 200 2 will be 
downloaded to feature card 20 so that it can provide both of these services. 

Figure 3 shows an embodiment of the feature card 20 of Figure 2. The 
feature card of Figure 3 receives, loads and executes the aforementioned 
"service specific" software images. The switch 322 observed in Figure 3 is used 
to direct ingress data from a particular line and channel (via the T1/E1 interface 
320) to an appropriate processor/software combination; and, direct egress data 
from its appropriate processor/software combination to a particular line and 
channel (via the T1/E1 interface 320). Thus, for example, a line/channel 
combination that is used to provide ATM service will have its ingress data 
directed: 1) from the T1/E1 interface 320 to the switch 322; and then, 2) from the 
switch 322 to a processor/software image combination configured to provide 
ATM functions. Similarly, in the egress direction, the same line/channel 
combination will have its egress data directed: 1) to the switch 322 from a 
processor/software image combination configured to provide ATM functions; and 
then, 2) from the switch 322 to the T1/E1 interface 320. 

Similarly, as another example, if another line/channel combination is used 
to provide Frame Relay services, the other line/channel combination will have its 
ingress data directed: 1) from the T1/E1 interface 320 to the switch 322, and 
then, 2) from the switch 322 to a processor/software image combination 
configured to provide Frame Relay functions. Similarly, in the egress direction, 
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the same line/channel combination will have its egress data directed: 1) to the 
switch 322 from a processor/software image combination configured to perform 
Frame Relay functions; and then, 2) from the switch 322 to the T1/E1 interface 
320. In this respect, the following excerpts from the Applicant's application are 
noteworthy. 



When a new network connection is being configured, 
a connection manager 340 identifies the type of 
connection set-up being requested. The connection 
manager 340 invokes the proper . . . software images 
. . . which are then downloaded into the local memory 
(318 and 326). The processors (316 and 324) 
execute the code associated with the software image 
200 which in turn programs the TDM switch to 
correctly manage the desired connectivity {i.e., TDM 
Switch to DSPMs in case of voice applications, TDM 
Switch to SCCs ports in case of [Frame Relay]/ 'ATM 
applications). 

Applicant's Application, page 12, lines 9-17. (emphasis added) 

With the above described hardware scheme, some 
timeslots in a single T1/E1 frame may carry 'Voice' 
while some others may carry 'data' and the timeslots 
are routed properly through the TDM switch 322 by 
programming the TDM switch 322 (e.g., voice- 
channel routed to the DSPM/s and data-channels to 
the SCCs) . . . 

Applicant's Application page 13, lines 9-13. (emphasis added) 

...[W]henever a new connection is being set-up, a 
higher layer software module such as a connection 
manager 340 detects the type of connection set-up 
being requested. In step 502, the higher layer 
software module then invokes the proper lower ... 
software image 200. For example, in order to support 
multiple types of applications, different software 
images 200T...200N are made available.... 
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Applicant's Application page 13, lines 19-24. 



In step 503, the desired software image 200 is 
downloaded to the on-board local memory. In step 
504, the code associated with the software image 200 
is then executed from the local memory and traffic is 
processed by the processors according to its 
corresponding software image 200. For example, the 
TDM switch 322 routes traffic according to traffic type 
as programmed by the corresponding software image 
200 (e.g., TDM Switch to DSPMs in case of Voice 
applications, TDM Switch to SCCs ports in case of 
FR/ATM applications). Once a particular type of 
software image 200 is resident in the local memory 
(318 and 326), for subsequent connection-setup of 
similar type (Voice/ATM/FR, etc.) the code execution 
simply continues from the local memory (318 and 
326) directly. 

Applicant's Application page 14, lines 2-1 1 . 

The above cited excerpts from the Applicant's application not only indicate 
that the TDM switch 322 appropriately routes traffic between the T1/E1 interface 
320 and the processors 316, 324 that execute service specific software (noting 
that the "service specific" software is loaded into memory 318, 326 made 
accessible to processors 316, 324); but also, the italicized items indicate specific 
software/processor combinations. That is, voice traffic is routed to/from the DSP 
modules 302i - 302 N (DPSMs); and, Frame Relay and ATM traffic is routed 
to/from the SCCs input/output ports of the processors 316, 324. Note that the 
second processor 324 is responsible for overseeing the DPSMs. See, 
Applicant's Application page 9, lines 13-24. 
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Applicant's Claims 

Applicant's claim 1 as amended recites: 



A method for a single hardware platform to support 
multiple types of network service, comprising: 

detecting a request to establish a network 
connection that flows through the hardware platform; 

determining a type of network service used by 
the network connection; 

downloading in response to the determining, to 
the hardware platform, software that is specific to the 
type of network service; and 

executing the software to process traffic over 
the network connection, according to the type of 
network service. 



Note that, with respect to the wording of claim 1 as it existed on April, 8, 
2002, the Applicant has chosen use of the term "type of network service" which 
is not only consistent with the detailed description of the present application but 
is also accurate with respect to the meaning meant to be conveyed to those of 
ordinary skill. Furthermore, the Applicant has discarded use of the term "on- 
board components". Furthermore, the Applicant has added a new claim element 
"downloading, to the hardware platform, software that is specific to the type of 
network service". 



In light of these amendments, the Applicant respectfully submits that U.S. 
Patent No.6,026,086 (hereinafter, "Lancelot") and U.S. Patent No. 6,041,058 
(hereinafter, "Flanders") can no longer be reasonably applied as a basis for 
rejection. 
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Lancelot at col. 9, lines 44-65 simply discloses that an access node 
("secondary station" 110) for traffic destined for either of two larger networks 
(circuit switched network 160, packet-based network 150) must pass a message 
(MOSJNFO) to an intermediary node ("primary station" 105) that requests usage 
of a larger network. It is correct that a concept having a large degree of overlap 
with a "type of network service" is embodied within the fourth byte of the 
message (see col. 9, lines 56-59); however, there is simply no relationship within 
Lancelot between this concept and the "downloading" and "executing" of 
"software to process traffic". This is made more clear by the failure of Lancelot 
to even mention the word "software" or "code" in that portion of Lancelot (col. 4, 
lines 33-45) cited by the Examiner as teaching "selectively executing] codes". 

Lancelot, therefore, not only fails to disclose each of the Applicant's claim 
elements, bit also fails to disclose a motivation or a suggestion that would be 
sufficient to allow the Examiner to combine Lancelot with another reference that 
could arguably be used to cover any of the Applicant's claims. 

With respect to Flanders, the Examiner reasoned that Flanders taught 
"selectively enable on-board components". As the Applicant has stricken that 
specific claim element, Flanders no longer applies. 

The Applicant has also added new claims 28-48. None of new claims 28- 
48 add new matter as they are well supported by the Applicant's specification. 
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Furthermore, each are of new claims 28-48 are patentable over Lancelot and 
Flanders for reasons similar to those stated just above. 

As such, believing claims 1 -6 and 28-48 to be patentable, the Applicant 
respectfully requests the allowance of same. 

Applicants respectfully submit the present application is in condition for 
allowance. If the Examiner believes a telephone conference would expedite or 
assist in the allowance of the present application, the Examiner is invited to call 
Robert O'Rourke at (408) 720-8300. 

Authorization is hereby given to charge our Deposit Account No. 02-2666 
for any charges that may be due. 



Respectfully submitted, 



BLAKELY, SOKOLOFF, TAYLOR & ZAFMAN 




Date: 




Robert B. O'Rourke 
Reg. No. 46,972 



12400 Wilshire Boulevard 
Seventh Floor 

Los Angeles, CA 90025-1026 
(408) 720-8300 
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CLAIM AMENDMENTS SHOWING CHANGES 

Please replace claims 1 -6 with the following claims, respectively. 
Please cancel claims 7-27. 

1 . (thrice amended) A method for a single hardware platform to support multiple 
types of network [traffic categories lservice . comprising: 

detecting a request to establish a network connection [tol that flows 
through the hardware platform; 

determining a type of network service [traffic category] used by the 
network connection; [and] 

downloading in response to the determining, to the hardware platform, 
software that is specific to the type of network service: and 

executing [code to selectively enable on-board componentsl the software 
to process fdata ltraffic over the network connection, according to the type of 
network [traffic category] service. 

2. (thrice amended) The method of claim 1 further comprising [invoking an 
appropriate one of a plurality of software modules corresponding to the network 
traffic category] configuring a switch to direct the traffic, after being received from 
a physical line that transported it. to a processor that performs the executing . 

3. (once amended) The method of claim 2 wherein the downloading further 
[comprising copying the appropriate one of a plurality software modules into a 
local memory on the single platform] comprises loading the software into a 
memory that the processor has access to . 
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4. (twice amended) The method of claim [2]1 wherein [one of the plurality of 
network traffic category being voice datal the type of networking service is a voice 
transportation service . 

5. (twice amended) The method of claim [2]1 wherein [one of the plurality of 
network traffic category being Asynchronous Transfer Mode (ATM)l the type of 
networking service is Asynchronous Transfer Mode (ATM) service . 

6. (twice amended) The method of claim [2]1 wherein [one of the plurality of 
network traffic category being Frame Relav)1 the type of networking service is 
Frame Relay . 

Please add new claims 28 - 48. 

28. (new) A method, comprising: 

downloading a first software image to a card that can execute the first 
software image, the first software image being specific to a first type of 
networking service so that the card can provide the first type of networking 
service over a physical line that emanates from the card; 

downloading a second software image to the card, the card also able to 
execute the second software image, the second software image being specific to 
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a second type of networking service so that the card can provide the second type 
of networking service over a physical line that emanates from the card; and 
downloading a third software image to the card, the card also able to 
execute the third software image, the third software image being specific to a 
third type of networking service so that the card can provide the third type of 
networking service over a physical line that emanates from the card. 

29. (new) The method of claim 28 further comprising loading the first, second 
and third software images into memory space that is available on the card. 

30. (new) The method of claim 29 further comprising executing the first, second 
and third software images so as to provide the first, second and third types of 
networking service. 

31. (new) The method of claim 28 further comprising providing the first, second 
and third types of networking service over a physical line that emanates from the 
card and that transports framed traffic. 

32. (new) The method of claim 31 wherein said physical line is a T1/E1 physical 
line. 

33. (new) The method of claim 28 wherein the first type of networking service is 
voice transportation. 
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34. (new) The method of claim 31 wherein the second type of service is ATM 
service. 

35. (new) The method of claim 33 wherein the third type of service is Frame 
Relay service. 

36. (new) The method of claim 28 further comprising configuring a switch that is 
located on the card to route traffic between a line interface that is located on the 
card and a processor that is located on the card and where the processor 
executes the second software routine. 

37. (new) The method of claim 28 wherein the downloading of the first software 
image is in response to a connection of the first networking service type being 
attempted though the card. 

38. (new) The method of claim 37 wherein the downloading of the second 
software image is in response to a connection of the second networking service 
type being attempted though the card. 

39. (new) The method of claim 38 wherein the downloading of the third software 
image is in response to a connection of the third networking service type being 
attempted though the card. 
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40. (new) A card, comprising: 

a) an interface to a physical line, the interface further comprising a line 
interface unit and a framer; 

b) a processor that can execute any of a plurality of service specific 
software routines that are downloaded to the card in response to a determination 
that the card is to provide any of a corresponding plurality of different types of 
networking services; 

c) a memory that is coupled to the processor and that stores any of the 
plurality of service specific software routines that the processor is expected to 
execute in response to the determination; and 

c) a switch that receives ingress traffic from the interface and routes the 
traffic the processor. 

41 . (new) The card of claim 40 wherein one of the types of networking services 
further comprises voice transportation. 

42. (new) The card of claim 41 further comprising a plurality of digital signal 
processors that help to provide the voice transportation service. 

43. (new) The card of claim 40 wherein one of the types of networking services 
further comprises ATM. 

44. (new) The card of claim 40 wherein one of the types of networking services 
further Frame Relay. 
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45. (new) A card, comprising: 

a) first means for interfacing to a physical line; 

b) second means for executing any of a plurality of service specific 
software routines that are downloaded to the card in response to a determination 
that the card is to provide any of a corresponding plurality of different types of 
networking services; 

c) third means for storing any of the plurality of service specific software 
routines that the second means is expected to execute in response to the 
determination; and 

c) fourth means that receives ingress traffic from the first means and 
routes the traffic to the second means. 

46. (new) The card of claim 45 wherein one of the types of networking services 
further comprises voice transportation. 

47. (new) The card of claim 45 wherein one of the types of networking services 
further comprises ATM. 

48. (new) The card of claim 45 wherein one of the types of networking services 
further Frame Relay. 
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